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SYSTEM AND METHOD FOR SENDING AND RECEIVING A VIDEO 
AS A SLIDE SHOW OVER A COMPUTER NETWORK 

The invraition relates to a systssn and method whereby a digitized audio- 
5 video ^le is reconfigured and downloaded oven a compatef network to a uaer 
tezminal in successive passes of data, 6o &at during or afker each pass* the user can 
see and hear the audio-video file with increasing quality. In a preferred 
embodiment, the audio-video file can be viewed as a high quality slide show wifli 
low bit rate audio during the download process and replayed as a video with fkill 
10 audio after cotnpletlng the download process. 

KAracr,T?n^nyp of tub HWRNTTnN 

Video data has extremely high storage and bandwidth requiiements. In order 
IS to reduce the bandwidth required to iiansmit video datat digitized video files can be 
compressed to reduce the data compriBmg the video file. During the process of 
video compression, video informfltion is deleted that would be imperceptible to the 
human eye. As more video data is deleted the size of the video file decrea^s and 
the bandwidth required to deliver the video file 1b reduced. A variety of methods 
2C and protocols exist for compressing digitized video fUee and are well known in the 
artr 

MPBO (Motion Pictures ExpeitB Group) is regarded by many as the standard 
for digital video compression. Videos produced in the MPEG format and played at 
25 a rate of 24 frames pei second provide high quality , high resolution video and high 
quality audio. 

MPEG video files, like other compressed video fUes, are (ftill rather large 
compared to smaller text and graphic ffles^ and can take ftom several minutes to 
30 hours of con$td4it data flow to download. High capacity host/client architecture 
capable of high storage and transmission rates is required to transmit and receive 
this data error^free without corruption or loss of data. In a distribuied computer 
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network such as the InteiDct, it Is difficult, if not impossible, to provide a host/client 
architecture which has the capacity for accaratei sustained, high speed transmission 
of large audio/video fiks. 

5 Bven where the capacity of the network distribution system ifi improved to 

permit more data transfer, a bottleneck typically occurs at the user modem which 
establishes the connection between the user and the network. A typical user modem 
only receives data at a rate of 28.8 kilobits per second. A 30 second MPEG video 
CM take 5 minutes or more to download over a 28.8 modem, Because the data is 
10 often transferred from afar, many factors can cause the loss of parts or all of a 
transmission^ thus slowing the receipt as re-transmission of the lost data occurs. 

Real time video delivery has even ntiore specific and stringent transfer and 
display timing requirements* In this case, the user wants to be able to view the 

13 vkleo at the user termteal while the video data is being downloaded, In order to dc 
thief, the line between the user teiminal and the server must have enough bandwidth 
to accommodate a steady stream of data comprising all the hiformatlon necessary 
for playing the video. If the bandwidth is not available, the data stream will be 
delayed during the download and there will be insuf&ient dat:a available at the user 

20 terminal to play back the video in real time, as it was ortglmUy encoded. As a 
result, the user will observe interruptions and delays In the video and audio intent. 

One atten^t to improve real time video delivery has been to further 
con^3ress the video. To accomplish this, some video content providers compress 

2s the video data by encoding at a slower frame rate of 6-7 frames per second (fps) and 
encoding the audio data at a lower bit rate, fheicby deleting large portions of 
content. The resulting video has poor quality and very choppy motion and the 
sound quality is poor. The video and audio data which is deleted during this 
coonpreaslon ptccesfr 1» permanently lost. Therefore, even if the download is 

30 successful, the quality of the video cannot be unproved; it will look and sound just 
as poor on subsequent replays* Bven at this reduced size, the video may consist of 
more data than can be iransruitted at the necessary viewing speed (in real time) over 
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a 28.8 kbaud modem, so tliat picture and sound quality is fUrther degraded when the 
user views it. 



Another solution involveB a con^ression format wherein data can be added 
5 to a video file during transmisfiion. to progresBively improve the image. As the 
video flie 1^ being downloaded* ilie content server Is cotujnuously testing the 
bandwidth of the network link to the user and making decisions on a firame-by-frame 
basis whether to pass more or less data to the user. As more bandwidth becomes 
availablep more data can be passed down and the qfuality of the video image and 
10 audio is improved. Like the previous examplei the video data is lost and cannot be 
recovered once the video file is downloaded. The resulting video ts of uneven 
quality, and subsequent repiaya will look and sound the &am&. 

Neither solution provides a means to transmit meaningful and enterCaining 
15 audio/video data to a user in real time that gives the user the option to replay the 
video in its original format, ].e.» a high quality video with high guali^ sound. The 
invention solves this problem by providing a method and system whereby a digitized 
audio-video flie can be reconfigured and downloaded over a computer network to a 
user terminal where it can be viewed as a high quality video slide show with low bit 
20 rate audio during the download process and replayed as a ftill-motion video with 
high quality audio after completing the download proceas. 

SUMMARY OF THE INVENTION 

23 In a first embodiment, the audio portion of an original audio-video (AV> file 

is compressed into a low bit rate (LBR) audio data stream by means known In the 
art. The order of the individual frames comprising the original video data stream is 
then rearranged. In a firet passp a frame selector module is used to select Individual 
video frames from among all the frames comprising the original video data stream. 

30 These frames will be stored at the front end of a reconfigured A V file along with the 

LBR audio stream. In subsequent passes, the imaining video frames are selected. 

3 
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The video frame data, LBR audio data soeam and audio data stream of the 
original AV file are then assembled as an AV file having a selectively reordered 
download Bequ&ncc and stored for delivery at a server site. When a video clip iB 
requested by a dient, the server downloads the video data to the client according to 
5 the selectively reordered sequence* As th& "front-loaded" portion of the new AV 
file» is downloadedp the client is able to view a comprehensive audio/video slide 
show representative of the whole video. 

The "front-loaded" portian of the new AV file comprising the slide show is 
LO many magnimdes in ^ize smaller than the original AV file (Fig. l>. ThuB^ even 
when the bandwidth available for transmission is limited* as is the caie with a 28. 8 
kbaud modern^ a high quality video slide show with audio can still he displ&yed 
during the download process because the data stream required to support the slide 
show and compressed audio is much smaller. 

15 

Once the slide show frames and LBR audio pordon of the new AV file have been 
downloaded* the remaining video frames and the original audio data stream are 
downloaded in stages, The client ^flware displays the fi^ont loaded data as a slide 
show during the download process and then resequences the front-loaded dau and 
20 remaining video franoes into the original order. This makes it poasible for the 
client's player to replay portions of the video clip as a low frame rate video during 
download. If all of the AV data is downloaded, the client software can display the 
video in its original format and speed with the originally recorded audio quality. 

25 In a second embodiment, the audio portion of an original AV file 1b highly 

compressed into an LBR audio data stream by means known in the art. A 
reconfigured AV file is created consisting of the LBR audio data stream^ the original 
audio data stream and a resequenced video data stream. The frame selector module 
is used to determine different download orders of video frame data for a variety of 

30 givffl connection speeds. A corresponding Index file is created for each download 
order. Hie index file records both the download order and information for locating 
the video data in the new AV file for reass^bly in the original order* A frame 
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sequencing inteiface (PSJ) is responsible for delivering AV files from the server to 
(he client. Tbt FSl, acnong other ftinciions, read& the index file that matches the 
client's connection speed and downloads the video firame data to the client according 
to the order recorded on the Index file. 

5 

In. both embodiments, the client software downloadG the file until the entire 
AV file is delivered or the user discontinues the download. As each pass of video 
data ifi downloaded, the client software reshuffles the data, into its original temporal 
order maiking It possible for the client to display the video data with progressively 
10 improved quality, Re^ftrdless of the number of firames downloaded, each frame is 
displayed with the fUll quality of the originally recorded video file. If all tbj& video 
dau iff downloaded the video can be displayed In lt$ orlgiioally reeotded condition 
with high quality audio. 

15 In both embodiments* dbe user has the option to stop transmission of a 

leconfigurod AV file at any point. The user can dect, for example, to see only the 
first ftame of the video> to view part or all of a slide show with LBR audio, to view 
a high quality video with LBR audio* or to view a progressively higher quality video 
with LBR or originally recorded sound. Thus* the user does not have to use up 

20 valuable bandwidth or time waiting for or viewing video content that does not 
significantly enhance the viewlt^g experience. 

In one embodimenti the dient software is configured to permit the fiill 
download to occur in the background so the user can perform other operations 
25 during the download prooesis. Once the video is completely downloaded^ the user 
can be signaled, and can replay the high qualiQ^ video. The client software can also 
interrupt, delay, and later resume the download process when It senses competition 
for the communication interfiice. 

30 TOTRTT T^RSrBTPTION nV THP. BP AWfNRR 

Fig. 1 is graph conq>arlng the size (in bytes) of an NfPEG video file, a low 

S" 
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frame rale video with low bit rate audio, and a video slide 9how with low bit rate 
audio; 

Fig. 2 is a block diagram representative of a scandard MPEG audio/vid^o 

5 Pig. 3 is a block diagram of a video delivery system according to tbe 

invention; 

Pig. 4 Is a flowchart illustrating the operation of a transcoder module 
according to Fig. 3; 

Fig. 5 igf a flowchart illustrating tfae operation of a frame Sector module 
10 according to Fig. 3; and 

Fig. 6 is a flowchart illustrating the operation of the video delivery aystem of 

Fig. 3. 

DRFTNTTTONS 

15 

Ttie terms used herein have their ordinacy meaning in the arc, and in 
addition> spwifici teime set forth b$Iow have the meaninge given, 

Slide Show. A sequence of vlfiual Images or frames presented as a condensed or 
20 slow-motion version of a video presentation or clip- In an embodiment of the 

invention, a slide show conoprises a sequence of video frames taken from an original 
full motion audio/video data file, rearranged and adjusted in timing and setjuence so 
as to make an attractive and synchronised presentation. A slide show may be 
presented with or without accompanying audio conloit 

25 

Vtden Clip. A video clip is a sequence, of any lengthy of images, with or without 
audio content (sound), defining a moving picture or aiumation. 

Audio/Video Data Pile. An audio/video data file is a digitized con5)uter file 
30 representative of a video clip. Tbe audio/video data file can be in any machine 
readable format and can be compresRed, or reduced in size, by any of several known 
compression techniqueSp such as MPEG. 
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Vidfto Data Stream. A video data Btream is that portion of an audio/video data file 
attributable to the storage of visual fanages. A vid» data stream typically comprises 
at least one sequence of video frames, in presentation or vienAring order, or indexed 
to represent a viewing order. Oth^r possible portions of an audio/video data file 
5 include an aiidio data stream and a system stream, such as a timing stream or an 
inde^E representative of a viewing order. 

Avj w SfTiRflm. An audio data stream is that portion of an audio/video data file 
attributable to the storage of audio content. An audio data stream may be made up 
10 of a sequence of audio frames. 

Video Frame. A video frame is a sii^gle static image taken from a video clip. A 
sequence of video frames, viewed in fkst succession, provides an illusion of motion. 

IS Audio Frame. An audio frame is a time-divided portion of an audio data stream. 
Audio frames typically are used for simplicity in handling and processing audio data 
streams; thjexe i& njQ necefifiary relationship between individual audio frames and 
individual video frames. Moreover, individual audio frames may vary in lej^th, 

20 Reconfigured Audio/Video (RAV^ Pile. An RAV file is prcxiuced from an 
audio/video data file, which may be referred to as an original or source file, and 
includes a video data stream having video frames in. a different presentation or 
viewing order than the original audio/video data file- An RAV file may have one or 
more video data streams and one or more audio data streams , one of which may be 

25 LBR audio. An RAV file may be produced or displayed in one or more passes, and 
may have less than, m;ore than, or the same audio and video information as the 
original audio/video data file. 

Presentation Order. A presentation order Is an order, or sequence, in which audio 
30 or video frames arc stored in an audio/video data file. In certain compreaaion 
schemes, such as MPEG, the presentation order of certain video frames may differ 
from the viewing otder» as certain video frames are decoded based on information hi 
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Other video frames wbich have not yet been diEpIayed, 
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Viftwmg Order. A viewing order is an order, or seqaence, in "which audio or video 
franws are displayed. Viewingordermay differ from presentation order. • 

5 

Lnw Bit RRfe Audio LBR audio is highly-compressed sound information 
derived from the audio content of an original audio/video data fite. In an 
embodiment of the inventioiij LBR audio frames are interleaved with video frames 
comprising a slide show, so that both the slide show video frames and the LBR 
10 audio framses can b& downloaded simultaneously and displayed in real-time; the 
original (non-LBR) audio data, stream can be downloaded at a later time. 

T^w Frame Rate Video. A low frame rate video l8 a slow motion or reduced- 
quaiity version of an original video clip. An audio/video data file representing a 
15 low frame rate video includes a subset of the video frames included In the original 
audio/video data file. 

Tranccnder Mndiile In an embodiment of the invention, a transcoder module is a 
combination of computer bardware and software that decodes an audio/video data 
20 file, extracts its video stream and audio stream, and optionally compresses the audio 
stream into LBR audio. 

FrHitie Selector Moduls. In an embodiment of ibe invention, a frame selector 
module is a combination of compufei hardware snd software that allows certain 
25 video firames to be selected from an audio/video data file for use in a slide show or 
low frame rate video. Information taken from the selection process is used to 
generate an RAV file or an index file. 

FrAmi^ 5;^^i^nr-ing TntierfacA rPSTV In an embodiment of the invcnlion, an PS! is 
30 used to generate a secoDd version of an RAV file» having a different viewing order 
or presentation order, from a fnst RAV file and an index file. The second version 
can then be transmitted over a communication link having different properties than 



wo 98/37699 

the one for wbicli the first RAV file was created. 
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llR&rTfermiiiftl. A computer system capable of displaying audio/video data fflee, A 
ura teiminal may H coupled to a cottmnixucations network, 

5 

Server. A computer system coupled to a commuTiications network, capable of 
transmittiiig (downloading) stored information to another computer system coupled 
to the network. 

10 nRTAn^RD PKsrRiPTrnN of the tiwentiqn 

For purposes of definitLon, the term video data* as used herein^ can mean 
both video frame data and audio frame data or just video frame data. To display 
video data mean^ to process an audio-video file in a computer so video images are 
15 displayed on the computer monitor and corresponding audio is broadcast on the 
computer speakers. Hie term playback or played back has the same meaning as 
display. 

The invention as described below and In each of the following examples is 
20 discus^ in terms of its application to the delivery of video data in the MPEG 
format, but the scope of the invention is not limited to the MPEG format or to the 
examples given. MPEG is one protocol fior compression of digitized video. There 
are a number of compression protocols which are used to reduce the sise of an AV 
file, i.e., JPEG. H261, Indeo, Cinepak* AVI, Quicktime, TrueMotion and Wavdet. 
2S The invention can easily be adapt&d by one skilled in the art to rcconfigUTB video 
data conq^ressed by any of these mjsthods, and sudi adaptations are within the scope 
of the invention. 

Regardless of the compression protocol used, the corresponding AV file 
SO would comprise an original audio data stream, an otigiial video data stream and a 
user stream containing information related to the synchronization and playback of 
the avdio/videc streams. The video data stream consists of encoded information for 
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video frames comprising aU of ffae picture inibrmtion for a given video* The video 
frames are anai^ged in a pieBele;:ted order so that when they ati& processed by a 
video player at a certain speed (frames per second) a fhll-modon video can l^e 
displayed. 

5 

In the MPEG format, a discrete coBine trflnsfarm compression algorithm is 
used to identify and delete redundant video Infbrmation both between frames and 
within an individual frame. The video stream of an MPEG movie oomprifies a 
series of video frames flanked by a header sequence and an end-of-sequence code. 
10 Much of the information in a frame within a video sequence is similar to 
information in the previous or subsequent frame. The MPEG standard ta]ces 
advantage of this temporal redundancy by lepresentii^ some frames in terms of 
their differences from other (reference) frames. 

15 The MPEG standard specifically de&ies three types of frames; intra, 

predicted, and bidirectionaL Intra (I) frames, are coded usii^ only infbrmation 
present in the fr^me itself and are present at unpredictable points within the 
sequential frames of compressed video data. Predicted (P) frames axe coded with 
respect to the nearest previous I or P frame. Bidirectional (B) frames axe frames 

20 that use both a past and fixture frame as a reference. I and P frames both serve as 
refierence frames for B frames. B frames are never used as a reference. 

The frequency and location of I frames is based on the need for random 
accessibility and the location of scene cuts in the video sequence. Whm random 
2S access is important, I frames are typically used two times a second. The MPBO 
encoder reorders the sequence of frames in the video stream co present frames to the 
decoder in the tnjost efficient sequence. In particular, the I or P reference frames 
needed to reconstruct B frames are sent before the associated B frames. 

30 The MFBG audio stream is similar to the MPEG video stream in that it 

contains an audio header sequence and one or more audio frames. It should be 
noted that individual audio frames do not necessarily correspond co individual video 
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frames. Audio frames are simply "packetlzed*^ vmion? of the audio data, that t$, 
the audio data stream divided into fcmit^ by any convenieiit or useiul means. For 
example, a particular audio con^rcsslon scheme used to create LBR audio might 
create frames of substantially equal size, but unequal duration. In contrast^ video 
5 frames typically have sufaBtaMially equal duration but unequal aize (hi particular, I 
frames are typically larger than P and B frames). 

The timing xoocihamsm that ensures synchroniLation of audio and video 
includes two parameters: a system clock <SQ and presentation dme stamps (FT5), 
10 The values for these timing mechanisms are coded in the MPEG bitstream. PTS are 
samples of the system clock that are associated with an individual video frame or 
audio frame. The PTS indicates the order and timing in which the video ftame is to 
be displayed or the starting playback time for the audio frame. 

IS The MPEG AV file consists of both a compression layer and a system layer. 

The audio and video data streams comprise the compression layer. The system 
layer contains timing and other information needed to demultiplex the audio and 
video data streams and to synchronize audio and video during playback* 

20 Fig- 2 shows a g«mli2»d decoding system for MPEG videos. The system 

decoder is responsible for extracting the timing information from the MPEG syBtem 
stream and sending it to the other system components, The system decoder also 
denxuItlplexeB the video and audio streams from the system stream and sends the 
data to tlie appropriate audio or video decoder. Chapter 10 of Video Demystified by 

25 Keith Jack, High Tcdi Publications, 1996, provides a fUe format fot implementing 
an MPBO video player that is incorporated by reference and can be adapted for use 
in the video delivery systm described herein. 

EXAMPLE ONE 

30 

A preferred embodiment of the video delivery system allows a user to 
download a video dtp In fbur passes, the first of whicb occurs in real time. The 
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system and metbod according to which the video delivery ie performed is di^ussed 
in detail below. 



With reference to Fig. 3, a reconfigured AV (RAV) fde 112 it C2%fltsd from 
5 an MPEG video and stored at a. server site 126 on the Internet, A dtent 132 at a 
user terminal builds a video request in the fbrm of a URL 130 containing the 
address of the stored fde. The client transmits the URL to the server 126, A 
connection is niade between the client and the aerver and the server downloads the 
file to the user termiml (receive sequencing interface) 72 hi its precoded order. The 
10 user termiml Initially processes and displays th& slide show data in the oxder it Is 
received, as it is being received. As addidonal data, downloaded, it is reshuffled 
with the alide show data in original fen^oral order making it possible to replay the 
video with progressively enhanced quality* 

15 TranBwter Modttls 

In Fig. 3. a transcoder niodule 120 is shown as a component of the content 
manager 118 of the video delivery system. As will be discussed below, the 
transcoder module 120 is used in the video delivery system to create an LBR audio 
20 data stream and prepare an MPEG video file for lesMjuencing. Accordingly, the 
transcoder module 120 is used m place of the system decoder of a standard MPEG 
player <Fig. 2) and performs a similar ftmction. 

With reference to Fig. 4^ the operations perfcrmed by the transcoder module 
25 are shown. Hie transcoder module 120 is used, to separate the compression layer of 
the MPEG file from an original system layer 20. The original system layer is 
discarded 22 and the tranBcoder module 120 then disassembles the remaining 
cont^xession layer into pure MPEG video and MPEG audio data streams 32 and 24, 
tespectlvely. The data streams 32 and 24 consist of sequential streams of bytes or 
30 charactersp 

The transcoder niodule 120 compresses the MPEG audio data stream 26 

U 
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using standard audio cotnpressian techniq^ies such as GSM (Global System For 
Mobile Telecommunicatioiis, an mtematiooal standard for audio compression) to 
produce a LBR audio data stream which requires tranBrnission bandwidth of 
approximately 13,000 bits per second or less. The tran6»:oder module 120 also 
5 associates 25 a copy of the corresp^^i^S P^S with each LBR audio frame 
indicating the display order of the audio data. Both the original MPEG audio 
component and the LBR audio component are retained for Incorporation iMo the 
RAVffle. 



10 The transcoder module 120, using markers embedded in the MFBG video 

data streamjs» locates all of the pure MPEG data necessary to construct a single 
video frame 34 and encodes that data 36 in an information block (see Table A), 
Each audio i^ame in the original MFBG and LBR audio component ie also encoded 
as information blocks 30 and 40. Bach block comprises one byte of block ID 

15 representative of the block type, followed by four bytes of block length* followed by 
the individual block data. 



20 



23 



30 



3S 



Table A 

(Information Blocks) 



Block Type 



Block Lengfc . 



Block Data 



N&xt BJcck Type 



Block LeaBth 



Block Data 



The file block types are: slide show file header block, I frame block, 

P frame block, B frame blocks video sequence header block, end of video file block, 

OSM (LBR) audio frame block, and MPEG (high quality) audio frame block. The 

layout of each type of block is shown in Table B. 

f6 



TABLES 



5 Slide Show Header Block 



Variable 


Description 


Size 


It^m TVP6 


Bicycle Type (1) 


Uiutansd Cbar 




Slzeof Headfir+d^ 


Lonfi 


Video BloclcB 


Number of Video Items 


Ungificied Short 


LHR Audio Blocks 


Number of LBR Audb Blocks 


UnBXKCied Short 


L3K Fratnflfi Per 
BJock 


Number of 33 niB samptcft b a 
Block 


Shore 


MFBO Audio Blcoks 


Number of MPEG Item^ 


Uim^ned Short 


Audio scan Time 


Offt et fcom start of Video 





I, P and B Frame BIcwks 



Variable 


Description 


Size 


ItexnType 


Block Type aOMQ2a03> 


Uzifllsned Cher 




Size of Header-t-Data 


Unal&Ded Lonx 


Frame Numder 


Prarceplay Kecmesce 


Up9lftiied Short 


Decode Feame Number 


^r&me decode wquence 


UnBissed Sbott 


l^ezuxtion 


Slide to SJlde Traiisitkm 


Short 


MFBO LoDAtLon 


Locafiot) in MFBG File 


Lotis 


PTS 


Presentatimi Time Stamp 


Lon2 


Slide PTS 


Slide Show FTS 


Lops 


VIDBO DATA FOR 
THB GIVEN FRAME 







Sequence Header, End of Video File, LBR Audio, vad MPEG Audio Blocks 





Variable 


Description 


Size 


40 


ItemTVpe 


Block Ty0» (103.104.20l.2a2) 










Unflisned Loms 




DATA FOR mB 
OIVBNTYPB 






45 









As the audio and video frame deta is oonverted to information blocks, tbe 
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blocks are stored in temporary files which, retain the data in its ori^nal stream order 
38, 42, and 44. As these jStes are created^ a temporary index file is generated which 
records information indicating in which files tiie sequential audio and video 
information blocks ate located 46. Finally, the index tables and data stream 
5 information are forwarded to a ftame selector noodule 48» as will be discuB^ed in 
detail below. 

10 The content manner 118 in Pig, 3 also includes a frame selector module 

116. The frame selector module is used to select the video data in successive passes 
for slide show and download sequencings and thus to encode the RAV and index 
flies. The operations performed by the frame selector module 116 are shown in 
Fig. S, The frame selector module 116 is used to select and assemble the dat^ that 

15 will be u&ed to build the RAV file 112. The frame selector module 116 picks the 
video frame data in successive passes using the index infiDrmation to choose and 
locate the respective information blocks. In a first pass^ the frame selector 116 
picks certain I frame blocks, Tiie chosen. I frames are intended to provide a 
conqsrebensive "dide show** sampling of the entire video, In a preferred 

20 embodimmt, I frames are chosen at a rate no greater than approTiimately one frame 
every two seconds. Where an esxemplary MPEG file contains two I frames per 
second, every fburth I frame would be chosen. 

The frames ttiat appear in the first pass are chosen zs follows; the average bit 
25 size of an I frame is computed 50. The target delivery bandwidth (for e^ian^le, 
28,80D bits per second) is multiplied by a typical usage f^tor (such as 10%) to give 
a pr^icted available bandwidth. The amount of bandwidth needed for the LBR 
audio is subtracted from the predicted available bandwidth to give the available 
video bandwidth in bits per second (this assures that there i£ always sufficient 
30 bandwidth to transmit the LHR audio error-free in real time). 

The average bit size of an I ftame is divided by the available video 
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bandwidtli to give the time needed to dov^oload the sIMe, In a preferr^ 
embodimentt ttus value is used as the tnfervsl between slides, unless the number is 
lo^s tban two secondfif in yfhltk ca$e two seconds ifi used as the interval. Bach sUde 
chosen is the one which ba$ its PTS closest to (but not less than) the next frame 
5 interval 52. The la^t I frame in the video is generally selected as a slide, and an 
end-of-pasB marker 15 associated with the last ftame 54, Accordingly, a slide show 
representation of a 5 minute (300 second) video would Include apptoximaiely 130 
selected I ftames. 

10 Bach selected I frame is marked with a second PTS 56 corresponding to its 

order and dming within the slide show. The frames are then stored in a temporary 
file according to their originai order. The second PTS makes it possible to vary 
when and how long each frame is displayed dunng the slide show. 

IS Once the frames comj^rising the slide show have been selected* the revised 

order of framcB is stored in a temporary video file and indexed 58. As will be 
discussed in detail below, the slide show can then be viewed frame-by-frame 60, 62 
1yy an operator using the video player component of the frame selector module 116. 
The video player utilizes standard MPEG video and audio decoders and has a 

20 rewind and replay function. The frame selector module 116 permits Ae operator to 
edit the slide show by adding or deleting firames 64 and 66^ or by substituting 
individual frames 68 in place of onee picked randomly by the frame selector module 
116. The frame selector 116 also allowB the operator to add, delete or change slide 
show PTS values 70 In order to vary when and how long a slide Is displayed. When 

25 the operator finishes editing, the frame selector begins 92 to write the actual RAV 
file which will be stored at (he server site. 

An RAV file header sequence is prepared containing information on the total 
number of video and audio firames In the video and the bit rate the download order 
30 was pi^ared for. The header sequence is encoded at the front end of the KAV file 
94. The infbrmation blocks representing the I frames chosen in the first pass and 
the corresponding LBR audio (die entire LBR audio data stream) are written into the 
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front end of the RAV file UZ immediat&Iy following the header sequence 96. The 
file is written ?uch that a portion of the LBR audio data precedes the initial 
correRponding I frame data. The remaining audio data i^ arranged in temporal order 
with the remaining I &ame data, however, the file is written such that an audio 
5 frame is always downloaded sometime prior to its corresponding video &ame. In 
tbiB manner, LBR audio data is always available to be played when the 
cotresponding slides are displayed. This address&s the experiecce that short gaps in 
audio playbacic are more easily disoernable, and more distracting* than short gaps in 
the visual »(ideshow presentation. 

10 

On the second pa90> the frame sdector 116 selects video frames whichp when 
played back with th^ video frames and audio data from the first pass» produce a low 
frame rate vid^ (1/4 to 1/2 the origmal frame rate) with LBR audio. Thxa video 
plays back with good to very good motion, However^ unlike the first pass, the 
IS Beoond pass need not be downloaded in real time. 

The frames on the second pass 74 are chosen in one of two ways, depending 
on the makeup of the MPEC file. If the total number of I fr^ames in the file is more 
than 23% of all frames 76» then approximately every iourth frame is chosen 78 

20 (unless that frame was already selected during the slide show pass). If the fourth 
frame is not an I frame, then flie next valid frame is chosen instead. If the number 
of I frames is less than 25% of the total number of frames, then the second pass 
consists of all the remainkig I frames plus all P frames 80. This results ixt a video 
which displays at apprt»xlmately 1/2 the original frame rate. The actual frame rate 

25 ulthnately achieved depend? on the combination of frames used to make the original 
video hut can be from 5 frames per second (fys) to 15 ffes, The quantity of data 
selected for the second pass Is typically more than is able to be downloaded in real 
time over a 28.8 kilobaud modem connection. 

30 The information blocks representing the video frame data chosen in the 

second pass are written into the RAV f!le immediately following the slide show 
Video ft«n.d.««<lliR««lio 98, 
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A third pass 86 includes all leroaining video frames which have not beeti 
selected in either of the two preceding passes. The infonnatioa blocks representing 
the video frame data chosen in the third pass are written into the RAV file 
iimnediatdy following the video frame data chosen hi the second pass 100. Like the 
5 second pass, the third pass comprises a quantity of data which is typically mone than 
is able to be downloaded in real time over a 28.8 kilobaud modem connection. 

In a fburth pass, the information blocks representing the MPEG audio data 
stream are written into the end of the RAV file, followed by the end of sequence 
10 block 102 and 104. Like the second and third passes, the fourth pass comprises a 
quantity of data which is typically more than is able to be downloaded in real time 
over a 28.8 kilobaud modem comiectioo, 

As discussed^ the second ^ thirds aiid fbuith passes may have more data than 
15 can be downloaded in real time. Accordingly^ the transfbr can take place in the 
background without user intervention^ For ejEampl&t if bl user is using the invention 
in the context of browsing the World Wide Web^ a certain Web page might contain 
a video dip. The user, by actuating a software control, can choose to receive the 
video clspp which is then displayed as a slide show in a portion of the Web page. If 
20 the user decides to download subsequent passes* the Ufiet: can continue to browse 
other Web pages as the download continues. When the download pass is complete, 
the user is alerted and given the option to return to the Web page containing the 
video to view the downloaded file, 

25 By way of example* th& previously described RAV file Is arranged to 

download over a 28.8 kilobaud channel in the following orden slide show frames 
and low bit rate audio in the first pass, video frames for building a low frame rate 
video ill the second pass, the remaining frames (frames for building the original 
MPEO video) in the ehird pass, and the high quality MPEG audio In the fourth pass. 

3D Oiven this arrangement, the slide show data and low bit rate audio would be 
downloaded or passed down first, so a slide show could be displayed during the 
download process. During the second and subsequent passes, the slide show and 
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low bit rate audio, or a higher quality presentation if mcsre data is available, is 
shown during thj> beginuiug of th^ dowldoad, After tfa« playback is finished, the 
download i% able to proceed in the background until the pass is completed. 



s If the ueer termina] is connect^ to th& network by a faster connection, more 

bandwidth Is available to transmit more video data. In this case« the content 
provider might elect to arrange the RAY file bo that video frames neoesflary to 
display a low-fhime-rate video could be downloaded or passed down first, at the 
same time as the low bit rate audio data. In this way, a Iow*irame-rate video with 

10 LBR audio , instead of a slide showi can be displayed during the initial download 
process. 



In the Latter case^ video frames which would normally be selected in a first 
and second pass would be selected in a first pass for iocoiporation into the front end 
15 oftheRAVfile. Tbe RAV file components would then be arrai^ged to download in 
the following preferred order: video frames for building the low frame rate video, 
the remahdng video ftames, and the MPEG audio. The LBR audio is preferably 
downloaded sonultaneoualy with the low frame rate video; alternatively, it can be 
downloaded before or after any of the RAV file components, 

20 

It is also possible to assemble RAV files comprising a variety of different 
download arrangements Including arrangements where audio data is downloaded 
last, or not at all, in which case a slide show or video could be displayed without 
audio. In this case, more fiiame data can be transmitted during the download 
25 process. These embodiments are also within the scope of the invention. 

The aaidio and video information blocks of the RAV fJle 112 would be 
pieatranged In the necessary download order for a given baud rate and stored in that 
order at the content provider's server sites as a data structure encoded on a 
30 computer-readable medium. 



When a client requests a video, a URL (UDiform Resouioe Locator) 
deBcribing the name and address of the file to be downloaded is traiisniitted to the 
server 126 storing tbe RAV file 112. The server 126 xtse$ the URL address to 
locate the RAV file 1 12. The server fhen forwards a URL to the Receive 
s SequcDcing Interface (RSI) 72 leqaestb]^ authorization to begin transmitting the 
RAV file 112. 



With reference to Fig. 3, the KS1 72 comprises a URL processor 130. a 
block tnuufer interface 128, frame builder 116, an index file generator 134, a franoe 
10 sequence table 140, an audio and video playlist 136, 138 and an MPBO video 
decoder/player The con^onents of the RSI 72 cooperate to receive and 
process video data at the user temiinal so it can be displayed. 

Upon notification of the URL processor 130, the RSI 72 establishes a 
IS TCP/IP connection to the server via (he block transfer interface 128 which starts a 
flow of block data from the server 126 to the RSI 72. The frame builder 1 16 stores 
the blocks of data in the order received so that the RAV file 1 12 Is reassembled. At 
the same time, the index iQle generator begins to construct tite audio and video 
playlists 136 and 138 and the frame sequence table 140. 

20 

The frame sequeaice table 140 is constructed from information extracted from 
the header of each video information block. The frame sequence table 140 has an 
entry for each block of video frame data. The layout of each enfiy is shown in 
Table C. The information in the frame sequence table 140 is used by the system 
25 sequencer 142 of the player 144 to locate video information blocks in the RAV file 
112. 
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TABLE C 
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Field 


Description 


iiem lypo 


isxiM M$9criDC inc JuiM or \msx uuit u id in^ vioeo rii& 

It ODuId be A Headexi A Group of Hnames, Start of Rrame, or 

CdilJ. ul FialJlOi oiCt4 


riaax lypt?' ^ 


IJ^ It W H UbCUiJVji ilLUI wUl UI& vyP*^ i» Ti OT O 




iiuB IB uic sci)ucnc& iriuidbT or luc ixnins in inc niD. rToinco 
fire nreflcnted cnit of nnier hecAU/iA RAm& ^A.tnftB' ti^Ad. cerlfllfi 

past and ftitur& frameft for decoding 


Dispi&y Order 


This Is ths ffiquAnclal Bram^ Number th^t would lie ^ov^n t£> 


PTS 


Preeeiitatiozi Ttoe Stamp for thit item, If it is a diBplnyable 


SliddTS 
(SdCAnd PTS) 


Pracut&tlon Time Stamp fbr fhi» slide's appeamnoe If it Is a 
dlflplayaUc frame In refloderad slide show 


Local Pi36 LdCAtidn 


The liOCACton of the Item In the RAV file, in bytee 


Ftl& Location 


LoeAtion Iti ihe aefUAl video flit 


Slide Tranalation 


How we SLO from oiie frame to anotbcx' 


Size 


Size of tbe item 



Frame Sequ»ice Table 



20 The video and audio playlista 138 aod 136 ace computed fiiom infoimRtion 

extracted from tbs RAV file headei sequenco. Each playllst cansists of a plurality^ 
of fttttries, and each entry stores data for an individual video or audio frame. Each 
playlist Is created with Hiough entries to accept informatioi] for every frame in the 
data stream. The Information stored in an entry in the playlist is shown in Table D. 

23 TABLED 



Field 


Description 


Index 


A pofiidve number la an ladex into tbe Frame Sec[ucnee Table 
N negative number i% a coxmnaiul to tlia ay^tem aequefioer: 

-1 Skip this frame 

-2 Sleep and retry &ame 


Replay Number 


Bvary time the uier replays the video, more and more fjamcH 
are available to view, the rqilay msmber tella yau whAt iqilay 
seouence thta allde Is pan of 



video Flayliat 



^1 
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Field 


Description 




An Itiidex bto the R AV File in bytu 



5 AudlD Playllst 



The video pUtyiist 138 tells ihe sysfeni sequencer 142 in what order the video 
frames are to be decoded In a given cycle. The video play list also contains pointers 
into the frame sequ^e table 140 for each item tkUy, 

Frame Builder Modale 



Fig. 6 diows the operation of the frame builder 116 and index file generator 
134. Initially, the video playliat 138 is created by the file generator 134 with a -2 in 
15 each index emry . A$ the first video frame to be played is downloaded 168, the 
frame aequence table 140 is updated 170, 172 with the location of that video frame 
block in the RAV file 112, and the negative number in the playlist 138 index entry 
correqjonding to that video ftame is updated a positive number 172 poinliqg 
into the frame sequence table 140. 

20 

When the next video frame is downloaded 1?6» the frame sequence table 140 
is updated 178 and the negative number in the video playlist 138 index oitry 
corresponding to that frame is updated with a positive number 180 into the frame 
sequence table 140. The negative two (-2) in each entry between the entries 
25 containing the positive numbers ie ^len changed to negative one (-1) 182, and the 
video data block is saved to the RAV file by the frame builder 184. As each video 
frame is downloaded, the process is repeated 186 until a positive number is entered 
in the video playlist 138 for every frame in the slide show and all of the intervening 
entries have been Ghanged £rom -2 to -1. 

30 

The audio playlist 136 contains pointers into the RAV file 112. There are 
two audio playlists, the first list will be a pointier Into &e LBR audio. The second 
Ust will be a pointer into the MPEG audio, Audio frames are stored by the frame 
builder into the RAV file in the same order ^ley are received 166. As each LBR. 
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audio block is received 162, the file generator registers the audio bloclcs die location 
in its corresponding eotry in the LHR audio playllst 220. 



Once the slide show frame data and LBR audio data have been downloaded^ 
5 the video frame data selected in the eeeond pass is downloaded 188r each video 
frame received, the fraine sequence table 140 is updated 190, a positive number is 
entered 192 in the corresponding entry on the video playlist 13B and the slide show 
PTS is deselected for every preceding video frame. The video data is thea saved to 
the RAV file 194 by the frame builder. Thi£ process is repeated for the video frame 
V> data which was selected on the third pa^s 196. After the third pass data is 

downloaded, the frame sequence table 140 would contain a complete record of all 
video frame data and the video playlist 138 would have a positive number in every 
entry, The order of frame data in the video playlist 138 reflects the same order in 
which data is presented by an MPEG encoder to an MPEG decoder. The 
15 presentation order is different than the display order. 

Once the second and third pass video data is downloaded, the MPEO audio 
data is downloaded 198, timiqg infozmatioiL i$ esctraeted 200, each audio frame is 
registered 202 in an entry in the MPEG audio pkylist 136» and the MPEG audio 
20 frame data is stored 202 in the RAV file< 

With reference to Fig, 3, the video player module 144 is shown. The player 
25 operates as a standard MPEG decoder/player, as shown in Hg. 2, except the 
standard MPEG system decoder is replaced with a system sequencer 142. The 
system sequencer 142 is responsible for synchronizing and directing the playback of 
the audio/video streams and Is invoked as soon as the frame builder module 116 
begins to receive the RAV file 112 from the server 126. 

30 

The system sequencer 142 detecraraes the next frame to decode by looking at 
the video and audio playliEts 156, 136 and the current status of the video and audio 
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output buffers 146, 148 of the player 144. Wheo the 5y&tem sequencer 142 reads 
through the video playlist ISB, it will r&frieve the corretsponding video &ame blook 
for each poeitive entry it comes to and forward the blocks ttom the IlAV file 1 12 to 
the video decoder 154 for decompressjoi). However, if the system sequencer 142 
5 sees that the video output bu£for 146 is M or the audio output buf£bx 146 i£ near 
empty» the system sequencer 142 will look to the audio playlist 136 to determine the 
next audio frame to decode and retrieve this audio block from the RAV file 1 12 for 
decoding, 

10 The video player module 144 decompresses audio and video frame data in 

the order presented by the system sequencer 142. Once decompressed, the video 
franaes are stored in the buffers and displayed in the order and for the length of time 
reference by the slide show PTS. 

15 If the user chooses to replay the dowdoaded data after the end of the slide 

show, the system sequencer 142 will read fhrough the video playlist 138 again 
decoding the corresponding video blocks fbr each positive number it comes to. 
Since more video frames will have been downloaded, more video frames will be 
available for decompression and the resulting video image will be enhanced. If all 

20 of the video frames in the second pass have been downloaded^ the system sequencer 
142 will be able to direct the playback of the low frame rate video with sound. 

In one embodiment, the system sequencer 142 is disabled from selecting 
video frames from the second or third pass for decoding until the last frame in that 
75 pas£ has been downloaded and the system sequencer 142 has read an end of pass 
marker. In that case, a display on the user terminal screen indicates when a given 
pass is downloaded ajid the uso^ can elect to replay the slide show or wait until the 
download is complete. 

Depending on the arrangement of video data in the RAV file 1 12 and the 
amount of data downloaded, the following i^n-lindtlng playback configurations are 
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possible: slide shorn, with or without LBR mdlo, where the video frame display 
rate Is from 1 frame every 10 seconds up to 4 iiramea per second^ a sttndard video at 
a preselected frame rate from as low as 4 ^6 to 24 Q)s, with or without IJSSi audio; 
an MPEG video (if all I, and P firaines are downloaded) with or without LBR 
5 audio; and, if (he Ml RAY file 112 has been downloaded, an MPEG video with 
MPBG audto can be a&eembled and played back. StaJidard videos with frame 
playback rates slower than 7.5 fps axe within the scope of the invention but are not 
desirable due to the poor image quality. 

10 ESAMPLEXm 

In this alternative embodimBnt, the RAV file 1 12 is created from an MPBG 
video as described in Example 1 and stored at a server site, However, the RAV file 
112 does not have to be downloaded in its prearranged order. Instead, the server 
IS she 1$ equipped with a frame sequencing mterface (PSI) which can reanange» in real 
time, the download order of the RAV file 112. 

With reference to Fig;. 7» a video distributiojc^ system is partitioned Into a 
content management system 118 which conq>rises the transcoder 120 and frame 
20 selector 116 programs, an FSI 204 which is located on the video pump 126 (the 
principal storage unit for the RAV files and index fries), a title manager 206 for 
processing video requests from the user terminal « and a client 208 which cxsmprises 
the RSI 72 piogrammii^ for recexving and dififplaying the RAV file 1 12 and the 
player 144. 

25 

The video distribution Bystem operates as follows* The user registers for the 
video service via client/title manager interaction. This process compiles user 
hardware and software configuration, prefbrences, and password data. 

30 The user, in interaction with the title manager 206, will select a video either 

from a video guide provided by the title manager or from a Web site. The title 
matiager then selects a URL specifying the address of the video at an appropriate 
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video pump, and tramsmits it to fhe client 208. Tbe client then requests this video 
by transmitting the URL to the video pump 204. 



The FSI and video pump system 204 respond by providing this video to the 
5 client 208 in a format and frame rate selected by fhe client, or one which match^ 
the hardware conilguration (e.g. modem, speed) of the particular user. If th& modetn 
speed will xiiOt support the download of a video, the user will receive a slide show 
with real-time LSR audio. As the amount of local video data increases during the 
downloading process as described above in connection with Example I, low frame 
10 rate videos can he displayed with progressively enhanced quality . Upon completion 
of the download, the user will be able to view the full frame rate MPBO audio/video 
presentation. 

With reference to Fig. 7, the MPBG video files are converted to RAV files 
IS 112 within the content management system 1 18 where the transcoder 120 and frame 
selector 116 programs reside. The transcoder 120 and frame selector 116 may 
perform the same fimction in the same way as described in Example L Thus, video 
data is selected in four passes and an RAV file 112 is created in which the video 
data is stored in the following order: slide show frames and LBR audio, low frame 
2D ratfi video frames, remaining video frame data^ and MPEG audio. 

At the same time the RAV file 112 is being assembled, a primary index file 
121 Clable E) is crented (9^ Fig. S, step 114) which contains a record of the 
download order of iofonnation blocks in the RAV flte 112 and infonoBtlon for 
25 locating each block in the RAV file or the original MPBG file. The prinmy hidex 
file is stored with the RAV file 112 at the server site 126. 



TABLE E 



Field 


Description 


Block download ord^ 


Block location in RAV File in bytes 



The frame selecdon process perform^^by the frame selector module 116 in 
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Example 1 is repeated so that download sequences far diilerent baud rates can be 
calculated. For instance, if the luer has an ISDN cotinectlon, k imy be possible to 
download sufficient data to play a low frame rat^ video with LBR audio during the 
download process instead of b slide show. In that case, the frame selector module 
5 116 would make a first pass and Sfdect all the frames necessary to make a low frame 
rate video (all the irames liiat were previously chosen in (he first and second pass) > 
The remaining video frame data would be selected on a second pass and the MPEO 
audio would be selected on a third and final pass as described in Example 1 . 

10 After the operator has finished makuig the final slide selection, the frame 

sdector 116, Instead of writmg a new RAV file, creates a secondary index file 122 
(Table E) which records the new download order and information about where ttie 
blocks are located in the origmal RAV file 112. 

IS The se«ondaty index files 122 are stored with the RAV file 1 12 and primary 

index file at the Berver site 126. A number of secondary indices would be prepared 
for a variety of different download arrangements and each index would contain 
pointers mto the same RAV file 1 12. Thus only one large AV file need be fiftored, 
along wifli a number of small index files 122. 

20 

When a user attend to download a RAV file usins a low bit rate 
connection (e.g. a 28,3 kilobaud modem), the RAV file 112 created by the content 
manager 118 will be downloaded directly by the video pomp 204, When a higher 
bit rate connection (e.g. ISDN) is used, the F51 204 will resequence the RAV file 
25 112, according to the information in the pdmaiy and secondary index files, so that 
the most appropriate sequence is used. AU of the frame selection, and ordering 
calculatiouB would hAve been made, in advance, in connection with the content 
manager 118» and stored in an appropriate secondary index file a& discussed above, 

30 With reference to Fig. 7, the content manager IIS is responsible fbi 

traniierriiig the RAV file 112 and index files to the FSI/video pump storage unit 
204, and upgrading the database of die title manager 206 to include the new video 
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clip title. Id a pieferred embodiment, the title manag&r 206 and PSI/video pumps 
would be located at the bead end in an Internet or intranet service provider facility 
or on an Internet backbone. 



5 With reference to Pig. 7» tbe PSI video pump 204 comprises a transfer 

monitor 124, storage for the SAV and index files 112 and 122, and a block transfer 
system 210. When (be server 126 receiveB a URL from the client ibr a particular 
video clip, the server creates a TCP/IP sock&t connection to the client'? RSI 72. 
The URL contains both address mfomiation into th& RAV file 112 and client 

10 information, The server 126 starts the transfer monitor 124 by passing the name of 
the file to be transferred and the connection speed of the useir to tbe tran^fiar 
monitor, 

The transfer monitor 124 searches the index files 122 for the secondary 
15 index that contains the download sequence for the given connection apeed. The 
transfer monitor 124 then uses the index 122 to locate the appropriate infbrmation 
blocks in the RAV file 112, so they can be downloaded according to tbe download 
sequence recorded in that index. 

20 In one embodiment, the FSI can respond tx) a u^ req[uest for a particular 

RAV file format. For example^ a user may elect to preview a slide show firsts even 
though tbe connection speed may accommodate the dov/nload and real-time display 
of a low-frame-tate video. In this case, the transfer monitor would accept the 
request and search the index files for an index which contains a record of a 

25 download sequence which is front loaded with $lide show video frames, such as the 
RAV file 1 12 descrilxd in example 1 . 



The transfer nu>nitor 124 then uses the secondaty index to locate the 
appropriate information blocks m flie RAV file 1 12, so they can be downloaded 
30 according to the download sequence recorded in that index 122. 

The ou^uc of the transfer monitor 124 comprises a series of infoxxnalion 
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blocks from the RAV file 112, transmitted according to the download segueoce 
reccttdwl in the appfopfiate secondary Jndest fUe 122, The referenced Uock% we 
then forwarded via the video pump TCP/IP block transfer system 210 to the client's 
RSI 72. 

5 

Once the PSI/vldeo pump 204 has delivered the data blocks to the RSI 72, 
the data is processed by the RSI 72 and video player as discussed in Example 1 and 
as shown in Figures 5 and 6. 

10 While certain exemplary stnicturee and operatlO]tx» have been described, the 

invention is not so iimited, and its scope Is to be determined according to the claims 
set forth below. 
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1 . A meftod for encoding and decoding an Eiidio/video data file, comprising 
the steps of: 

obtaining a digitized audio/video data file compming a video dafa stream 
representing a sequence of video frames having an original order and a first timing 
mechanism for indicating the display' ord^ of the video frames; 

decoding the audio/video data file into at leaat Its coniponent video data 

stream; 

reordering the video frames in &e video data stream; 
aBsembling a reconfigured audio/video file comprising the reordered video 
frames; and 

displaying the reordered video frames according to a second timiqg 
mechanism* 

2. The method of claim 1 » further compriaing the step of rearrai^ging the video 
frames according to the original order bo the origmal audio/video data file can be 
displayed. 

3. The method of claim 2, ftirther comprising the stepfi of: 

decoding the audio/video data file into its component audio data stream; and 
compressing the audio data stream to produce a low bit rate audio data 

stream. 

4- The method of claim 3 , wherein ttie assanblmg step further comprises the 
step of incorporating the low bit rate audio stream into the reconfigured audioyvideo 
fUe. 

5 . The method of claim 4, wherein the assemblmg step further comprises the 
step of associating the second thning mechaniBm with the low bit rate audio data 
stream to synchronize the low bit rate audio data stream to the reordered video 
frames. 

3<> 
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6. Tbe method of claim 1, wherdo the reordering step furOier compriEcs ttie 
steps of: 

selecting video frames that can be used to assemble a slide show having a 
first preselected display rate; 

assocladng the video frwies in the slide show with the second timir$ 
mechanism to indicate the display order and timing of display of each slide show 
frame; and 

selecting video frames which can be combined with the video framea selected 
in previous passes to asfiemble a video file having a second, higher^ display rate. 

7. The method of daJm 6» ilirther comprising the step of selecting all remaining 
video frames not previously selected. 

8. The method of claim 7, fhrther comprising the stsp of storing the video 
frames in a reconfigured audio/video file. 

9r The method of claim 1 , further comprising the steps of: 

receiving and processing a request for fhe reconfigured audio/video file from 

a user terminal; and 

dowDioading tbe reconfigured audio/video file from a storage unit to the user 

terminal in the selectively reordered download sequesice. 

10. Tbe method of clann 9, wherein the download is accomplished in at least two 
passes. 

11. Hie method of clahn 10, wherein the download is accon^lished in four 
passes. 

12. The method of clahn 11 , further comprising the &tep of arranging the video 
frames for downloading in the following order: slide show frames, subsequent pass 
video frames, final pm video f^ame£< 

3f 
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13 . The method of claim 1 1, further compming the step of aixanging the 
reconfigured audio/video file for dowiloading in the following order; elide show 
frameBt subsequent pass vid&o frames » final pa^^ video fratnes, originai audio data 
Btreain. 

14- The method of claim 10^ flirther camprifiing the step of arranging the video 
frames for downloading in the Mowing order; low frame rate video ftames> 
subBequent pass video frames. 

15 . The method of claim 1 , wherein the assembling step flirther comprises the 
fltep of creating an index file representative of an order for the reconfigured 
audio/video d^ta file. 

16. The method of claim 1, wherein preparing the reordering step conqirises the 
st^s of: 

usii^ a frame selector module in at least two successive passes to select and 
identify appropriate video frames and their download order; and 

creating £UQd updating an index Hie with a ti;ming and a sequence for each 

frame. 

17. A system for encoding and decoding an original audio/video data file having 
an original ordeT, comprising^ 

a transcoder module for decoding the original audio/video data file into a 
video data stream; 

a frame selector module for specifying a reordered sequence for the video 
data stream; 

a storage unit comprising a computer readable medium^ for storing a 
reconfigured audio/video file representative of the original audio/video data file hi 
the reordered sequence; and 

a user terminal through which a user may display the reconfigured 
audio/video file. 

3Z 
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18, The system of claim 17, further comprising: 

a frame s&queiicing interface for retrieving and sending the reconfigured 
audio/video file from the storage unit to the user terminal; and 

a receive sequencing interface fbr downloading and processing the 
recoiifigured audio/video file for display. 

19, The system of claim 18, wherein the transcoder module is enable of 
decoding ^ original audio data stream from the original audio/video data file and 
compressing the original audio data stream into a low bit rate audio data stream. 

20, The system of claim 19> wherein the tran^der module creates a plurality of 
data files representative of the video frames of the original audio/video data file, the 
original audio data stieami and the low bit rate audio data stream. 

2L The system of claim 17p wherein the reconfigured audio/video file comprises 
an original audio data stream, a low bit rate audio data sbream, a video data stream, 
and a first timing mechanism associated with each stream indicating a display order 
for the audio stream data and the video stream data. 

22. The system of claim 21 , wherein the video data stream of the reconfigured 
audio/video HLe comprises data representing a sequel of video frames. 

23. The system of claim Ift^ wherein the video data stream of the reconfigured 
audio/video file is ordered so that video ftiames con^rising a slide show are 
downloaded first. 

24. The system of claim 23 , wherein the reconfigured audio/video file is ordered 
so that the low bit rate audio stream is interleaved with video frames comprising the 
slide show, such that the slide show with tow bit rate audio can be displayed while 
the data is being downloaded. 

25 . The system of claim 24, wherein the reconfigured audio/video file is 

^3 
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Btructiired such ttuat additional video. frmSr data is downloaded after the data 
comprising the slide show and low btt fate audio. 



26. The system of ckim 25 , whei&cn the reconfigured audio/video file h 
rearranged into its original order. 

27. The system of claim 26, wherein fbe original audio/ video data file has a 
video frame rate between approximately four frames per second and approximately 
thirty frames per second, 

28. The Bystem of elaim wherein the original audio data stream is 
downloaded after all video data Btream infornmiion. 

29. The system of claim 17, wherein the reconflguned audio/video file is 
arran^ for playback according to its original order, 

3Q . The system of claim 23, wherein each video frame in the slide show is 
associated with a second timing mechanism to indicate a display order and time. 

31. The efystem of claim 30, wherein the slide show has a display rate between 
Eqiproximately one frame every fen seconds and approximately four frames per 
second. 

32. The system of claim 31, wherein the display rate is approximately one frame 
every two seconds. 

33 . The system of claim 31 , wherein the display rate is variable. 

34. The system of claim 24, whereia the low bit rate audio stream has a 
transmission bandwidth between approxhnately twelve and i^ptoximately fourteen 
kilobits per second. 
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33 . The system of idaim 18, wherdn the video data file is reordered so that 
video franiei eomprisiog a low frame rate video are downloaded first, so that the 
low frafloe rate video can be displayed while the data is being downloaded. 

36. The system of elaim 3J, wherein the video data file is reordcied &o that the 
low bit rate audio stream is passed down at the same time as the video frames 
comprising the low frame rate video, such that a low frame rate video with low bit 
rate audio can be displayed while the data is being downloaded. 

37. The system of claim 18, wherein the frame selector module pcqiares an 
indess file representative of an order for the reconfigured audio/video file. 

38. The system of claim 37, whereui the frame fiequencing intediaDe utilizer the 
index file to create a reconfigured audio/video file for downloadtog, 

39< The system of claim 38, wherein the frame sequeiul^ing ititerface selects and 
downloads video data in an appropriate order selected from one of the following 
orders: 

a) alide show frames » low frame rate video frames » tuitjsr frame rate video 
frames; 

b) low frame nate'video frames, faster frame rate video frames; 

c) slide show frames with low bit rate audio, low frame rate video frames, 
fiister frame rate video frames, original audio; 

d) , low frame rate video frames with low bit rate audio, faster frame rate 
video frames, original audio; 

40. The system of claim 39, wherein the appropriate order is selected according 
to a download speed. 
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